\documentclass[a4paper]{article}
\usepackage{float}
\usepackage{fullpage}
\usepackage{graphicx}
\usepackage[dutch]{babel}
\usepackage{multirow}
\usepackage{hyperref}
\setlength{\parindent}{0pt}
\setlength{\parskip}{2ex}
\title{OSS: Iteratie 2}
\date{}
\author{Your Name}
\begin{document}
\includegraphics[height=3cm]{logo.png}
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\begin{center}
\begin{Huge}
Ontwerp van Softwaresystemen: Iteratie 2
\end{Huge}\\
\vspace{1cm}
\textbf{Groep 1}\\
Billen Niels\\
Dommicent Leendert\\
Dusart Thibaut\\
Van Loock Jorn\\
\vspace{1cm}
Prof. Roel Wuyts\\
Begeleider: Dries Vanoverberghe\\
\end{center}
\newpage
\tableofcontents
\newpage
\section{Inleiding}
Dit verslag handelt over de aanpak en de resultaten van de tweede iteratie van het project, waarbij er een uitbreiding gevraagd werd van het bestaande programma BlueJ. Vooreerst wordt de opgave en zijn vereisten geanalyseerd. Vervolgens een ontwerphoofdstuk met daarin onze ontwerpbeslissingen en de implementatiedetails van de verschillende onderdelen. Het daaropvolgend hoofdstuk beschrijft welke onderdelen van de uitbreiding getest zijn en de aanpak van de testen. De laatste drie hoofdstukken bevatten het project management wat de verdeling van de taken binnen het team beschrijft, een discussie en conclusie en tot slot een glossary of terms.
\section{Analyse}
\subsection{Vereisten}
In de uitbreiding wordt gevraagd om de object bench aan te passen, zodat de gebruiker snel een overzicht krijgt van de actieve objecten in het programma en hun relaties. In de huidige versie van BlueJ moet de gebruiker immers al de objecten gaan inspecteren om te weten te komen welke objecten met elkaar interageren. Daarom moet het mogelijk zijn voor de gebruiker om de objecten te visualiseren in een grafe die de relaties tussen de velden van de objecten toont. Bovendien moeten velden met behulp van een filter verwijderd kunnen worden van de graaf samen alle objecten waarnaar niet meer verwezen wordt. Bovendien moeten complexe objectstructuren verborgen kunnen worden als een compacte tekenreeks (een ArrayList met elementen 0, 1 en 2 kan bijvoorbeeld compact weergegeven worden als de String \{0,1,2\}).

\subsection{Use Cases}
Use cases beschrijven de stappen en acties die een gebruiker (of actor) moet doen om in een systeem een bepaald doel te bereiken. Ze geven dus aan hoe de gebruiker interageert met het systeem. Dit ontwerpdocument is dan ook de basis voor het ontwerp en ideaal om de vereisten van het systeem weer te geven.

\subsubsection{Use Case 1: Methode aanroepen}
{\bf Hoofdactor:} Gebruiker\\
{\bf Secundair:} Systeem\\
{\bf Precondities:}
\vspace{-6mm}
\begin{itemize}
\item Er is een klasse aangemaakt.
\vspace{-2mm}
\item Er is een object aangemaakt.
\end{itemize}
\vspace{-5mm}
{\bf Postcondities:}
\vspace{-6mm}
\begin{itemize}
\item Nieuwe objecten staan in de grafe.
\vspace{-2mm}
\item Associaties tussen de nieuwe objecten zijn aangemaakt.
\end{itemize}
\vspace{-5mm}
{\bf Scenario:}
\vspace{-6mm}
\begin{itemize}
\item Methode wordt aangeroepen door de gebruiker.
\vspace{-2mm}
\item Parameters worden door de gebruiker ingevuld in het tekstvenster.
\vspace{-2mm}
\item Het object verschijnt in de originele \textit{ObjectBench}.
\vspace{-2mm}
\item De objecten worden weergegeven op de grafe samen met de interconnecties.
\end{itemize}

\subsubsection{Use Case 2: Filteren}
{\bf Hoofdactor:} Gebruiker\\
{\bf Secundair:} Systeem\\
{\bf Precondities:}
\vspace{-6mm}
\begin{itemize}
\item Er is een klasse aangemaakt.
\vspace{-2mm}
\item Er is een object aangemaakt.
\vspace{-2mm}
\item Het frame waarin de grafe getekend werd staat open.
\end{itemize}
\vspace{-5mm}
{\bf Postconditie:}
\vspace{-6mm}
\begin{itemize}
\item Nieuwe grafe wordt weergegeven volgens de ingegeven filter.
\end{itemize}
\vspace{-5mm}
{\bf Scenario:}
\vspace{-6mm}
\begin{itemize}
\item (Optioneel) Gebruiker drukt rechtsboven op help.
\vspace{-2mm}
\item (Optioneel) Helpvenster springt open met informatie over de syntax van de filterstring.
\vspace{-2mm}
\item (Optioneel) De gebruiker sluit dit venster.
\vspace{-2mm}
\item Gebruiker vult een filterstring in, in het textvak vanboven aan de grafe.
\vspace{-2mm}
\item Gebruiker drukt op de filter knop rechts van dit tekstvak.
\vspace{-2mm}
\item De grafe wordt aangepast volgens de ingegeven filterstring.
\end{itemize}

\subsubsection{Use Case 3: Object aanmaken}
{\bf Hoofdactor:} Gebruiker\\
{\bf Secundair:} Systeem\\
{\bf Precondities:}
\vspace{-6mm}
\begin{itemize}
\item Het BlueJ venster staat open.
\vspace{-2mm}
\item Er is een klasse geschreven.
\end{itemize}
\vspace{-5mm}
{\bf Postconditie:}
\vspace{-6mm}
\begin{itemize}
\item Aangemaakt object staat in de originele \textit{ObjectBench}
\vspace{-2mm}
\item Een venster met de grafe springt open
\end{itemize}
\vspace{-5mm}
{\bf Scenario:}
\vspace{-6mm}
\begin{itemize}
\item Gebruiker klikt met de rechtermuisknop op de klasse in het venster van BlueJ
\vspace{-2mm}
\item (Optioneel) Helpvenster springt open met informatie over de syntax van de filterstring.
\vspace{-2mm}
\item (Optioneel) De gebruiker sluit dit venster.
\vspace{-2mm}
\item Gebruiker vult een filterstring in, in het textvak vanboven aan de grafe.
\vspace{-2mm}
\item Gebruiker drukt op de filter knop rechts van dit tekstvak.
\vspace{-2mm}
\item De grafe wordt aangepast volgens de ingegeven filterstring.
\end{itemize}

\subsection{Domeinmodel}

\section{Ontwerp}
\subsection{Inleiding}
In dit hoofdstuk worden onze ontwerpbeslissingen overlopen. In de eerstvolgende twee subsecties worden de klassendiagrammen en interactiediagrammen weergeven. Daarna leggen we onze aanpak en gemaakte keuzes uit. Er staat gedetailleerd uitgelegd waarom we een bepaalde keuze maakten, wat hiervan de voordelen en nadelen zijn en hoe we die ge\"implementeerd hebben door gebruik te maken van bestaande OOP-patronen. Hierbij wordt er continu gerefereerd naar de klassendiagrammen.
\subsection{Aanpak}
De opgave geeft een grote vrijheid om de implementatie van de object grafe te implementeren. Eenderzijds kon de bestaande object bench van BlueJ uitgebreid worden om de grafe te tonen. Deze aanpak genoot echter niet de voorkeur omdat we uit de eerste iteratie reeds konden concluderen dat het grafische aspect en de onderliggende functionaliteit van BlueJ niet strikt van elkaar gescheiden zijn. Bovendien opent BlueJ voor elke \textit{package} een apart venster, waarin een nieuwe \textit{object bench} staat. Het is dus onmogelijk om de relaties tussen de objecten op de verschillende \textit{object benches} correct te tonen, zonder al de objecten en hun interrelaties te tonen op al de \textit{object benches}. Daarom wordt de grafe getoond in een apart venster. Deze aanpak heeft een minimale impact op de code van BlueJ, maar heeft als nadeel dat er weinig tot geen hergebruik is van de klassen van BlueJ.

\par 
Uitgaande van deze beslissingen kan het project opgedeeld worden in twee delen: het ophalen en filteren van de objecten en het grafische aspect.  Het eerste deel moet uit de bestaande code alle aangemaakte objecten kunnen verkrijgen waarop een filter toegepast kan worden. Het grafische gedeelte moet de objecten die uit de filter komen correct en duidelijk kunnen weergeven samen met al de interacties tussen de objecten. De gebruiker moet de mogelijkheid hebben om via deze grafische interface een filter toe te passen op de objectbench om zo alleen de objecten en velden te zien die hij wil zien.

\newpage
\subsection{Klassendiagrammen}
\subsubsection{Object grafe}
Figuur \ref{fig:klasdiagramgraph} toont het klassendiagram van de object grafe. Centraal staat de klasse \emph{GraphFrame}. Deze is een subklasse van de klasse JFrame en gaat dan ook het venster voorstellen waarin de gebruiker de object grafe in zal zien, de filter kan toepassen en de layout kan wijzigen. \emph{GraphObjects} stellen objecten voor die direct of indirect door BlueJ gegenereerd worden. \textit{GraphFrame} gebruikt de klasse \textit{GraphComponent} om deze \emph{GraphObjects} op te tekenen. De \emph{GraphObjects} worden geplaatst door de subklassen van \emph{GraphPlacementStrategy}. Deze heeft twee subklassen, namelijk \emph{GridLayout} en \emph{CircularLayout} die de \emph{GraphObjects} respectievelijk op een raster en op een cirkel plaatst. Om de \emph{GraphObjects} te verbinden gebruikt de \emph{GraphComponent} subklassen van de interface \emph{LineStrategy}. Deze interface  biedt de mogelijkheid om meerdere strategie\"en te implementeren. Voorlopig  wordt deze enkel ge\"implementeerd door de \emph{NaiveLineStrategy}. Deze verbindt de \emph{GraphObjects} met behulp van de klasse \emph{RectangularLine}.

\begin{figure}[p]
\centering
\includegraphics[width=0.78\textwidth]{diagramgraph2.png}
\caption{Klassendiagram van de object grafe}
\label{fig:klasdiagramgraph}
\end{figure}
\par 


\subsubsection{Objectendatabase}
De objectendatabase houdt al de objecten bij die in BlueJ zowel rechtstreeks als onrechtstreeks gemaakt worden. Dit gebeurt door al de velden van de objecten in de originele \textit{objectBench} recursief te scannen naar nieuwe objecten. Deze database kan veranderen wanneer er een nieuw object wordt aangemaakt of wanneer er door de gebruiker een methode op een object wordt aangeroepen. Als dit gebeurt, wordt heel de database opnieuw opgebouwd. Hoewel dit zorgt voor onnodig werk, is dit wel de meest veilige optie om geen objecten over te slaan. In de code wordt de database voorgesteld door de klasse \textit{ObjectBench}. Deze heeft een methode \textit{getInstance()} die het object teruggeeft van deze klasse. De \textit{update(List$<$ObjectWrapper$>$ wrapperList)} methode update de database met de gegeven lijst van \textit{ObjectWrapper} die in de originele \textit{ObjectBench} zit. Al de objecten worden opgeslagen als een \textit{ObjectRepresentation}. Deze klasse bevat het \textit{DebuggerObject} van het object. Dit is een klasse van BlueJ zelf die informatie bevat over het object. De \textit{ObjectRepresentation} bevat ook een unieke id en een lijst met objecten die naar hem verwijzen met hun velden. In figuur \ref{fig:klasdiagramobjectlist} staat het klassendiagram van beide klassen.
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{klassendiagram_objectlist.png}
\caption{Het klassendiagram van \textit{ObjectList} en \textit{ObjectRepresentation}}
\label{fig:klasdiagramobjectlist}
\end{figure}

\subsubsection{Filter}
De \textit{ObjectList} heeft ook een methode filter die een StartFilter aanmaakt en daar de methode \textit{join()} op aanroept. Het klassendiagram van de filter staat in figuur \ref{fig:klasdiagramfilter}.
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{klassendiagram_filter.png}
\caption{Het klassendiagram van de filter}
\label{fig:klasdiagramfilter}
\end{figure}
\begin{itemize}
\item \textbf{StartFilter}: De StartFilter zorgt voor het starten van het filterproces. Dit is de bovenste knoop van de filterboom.
\item \textbf{FilterHierarchyObject}: Deze klasse verzamelt alle objecten die in de filterboom kunnen zitten.
\item \textbf{LogicalFilter}: Van deze klasse erven alle logische filters over. Het bepaalt de structuur en zorgt voor de opdeling van de reguliere expressie op basis van de juiste operator.
\item \textbf{OrFilter}: De voorstelling van een 'of' filter. Hier voegt men de resultaten samen van de onderliggende takken in de filterboom op de manier zoals een 'of' filter het zou doen.
\item \textbf{NotFilter}: De voorstelling van een 'niet' filter. In deze klasse worden de tegenovergestelde velden, van de doorgekregen resultaten van de onderliggende tak, doorgegeven naar boven in de filterboom.
\item \textbf{AndFilter}: De voorstelling van een 'en' filter. Deze houdt de gemeenschappelijke resultaten bij die doorgegeven zijn door de onderliggende takken in de filterboom.
\item \textbf{FilterObject}: Dit zijn de bladeren van de filterboom. Deze doen de eigenlijke filtering op de aangegeven parameter. Hiervoor is de volledige lijst van velden en dergelijke nodig van ObjectList.
\end{itemize}
In figuur \ref{fig:filterboom} staat een voorbeeld van een filterboom. Het begint bij een startfilter. Deze \textit{parst} de eerste operatie die moet verwerkt worden volgens de prioriteitsregels van de ingegeven filter. De filter wordt vervolgens opgesplitst volgens deze operatie en een corresponderende \textit{LogicalFilter} wordt aangemaakt.\par
\textbf{Voorbeeld}: Filter: 'A of B en C' wordt opgesplitst in 'A of B' langs de ene kant en 'C' langs de andere kant van een \textit{AndFilter} omdat 'en' prioriteit heeft over 'of'.\par
De \textit{parse} methode zit in \textit{FilterHierarchyObject} en kan dus door elke methode van de filter aangeroepen worden. Deze zorgt voor de aanmaak van de juiste kinderen op basis van de operator met de hoogste prioriteit. Zoals in het voorbeeld weergegeven, zorgt \textit{StartFilter} door middel van de \textit{parse} methode voor de aanmaak van een \textit{AndFilter}. Deze gaat op zijn beurt weer de \textit{parse} methode aanroepen die voor het linkerdeel van de \textit{AndFilter} een \textit{NotFilter} aanmaakt, en voor het rechterdeel een \textit{OrFilter}. Zo gaat het proces verder tot er geen operatoren meer in het overgebleven deel van de filter te vinden zijn.\par
Op dit moment maakt de \textit{parse} methode een \textit{FilterObject} aan dat voor het evalueren van dit deeltje van de filter zorgt. Dit bestaat nog uit een parameter die aangeeft waarop er gefilterd moet worden en een reguliere expressie die toegepast moet worden op het aangegeven deel. De mogelijke parameters betekenen het volgende:
\begin{itemize}
\item \textbf{v}: naam van het veld
\item \textbf{t}: type van het veld
\item \textbf{w}: waarde van het veld
\item \textbf{k}: naam van de klasse
\item \textbf{p}: naam van het pakket
\item \textbf{o}: op het object
\end{itemize}
De structuur van de filter ziet er als volgt uit: elke parameter wordt gevolgd door een dubbelepunt en daarna accolades waarin de reguliere expressie staat. Een (slecht) voorbeeld hoe men arrays kan filteren uit onze \textit{objectbench} is: \textit{niet t:\{[A-Za-z0-9]+\textbackslash[\textbackslash]\}}. Operatoren moeten steeds gevolgd worden door een spatie en indien ze niet aan het begin van de filter staan moeten ze ook voorafgegaan worden door \'e\'en.\par
Als al de filterobjecten een lijst hebben gemaakt van velden die voldoen, moeten al deze lijsten worden samengevoegd. Hiervoor wordt de \textit{join} methode gebruikt. Deze methode verschilt voor elke \textit{LogicalFilter} en voegt de lijsten bij elkaar volgens de regels van 'en', 'of' en 'niet'. Dit wordt dan recursief uitgevoerd naar de bovenkant van de boom tot bij \textit{StartFilter}.\par
Eens de lijst bij \textit{StartFilter} is, wordt er nog gecontroleerd of er objecten zijn waar niet meer naar verwezen wordt. Deze worden dan nog verwijderd uit de lijst en het resultaat daarvan wordt teruggegeven bij de filtermethode. 
\begin{figure}[ht]
\centering
\includegraphics[width=0.6\textwidth]{filterboom.png}
\caption{Een voorbeeld van een filterboom}
\label{fig:filterboom}
\end{figure}

\subsection{Interactiediagrammen}
In figuur \ref{fig:sequentiefilter} staat een sequentiediagram van de filter methode. Dit diagram geldt voor een filterstring die twee filters verbindt met de logische operator 'en'. Eerst wordt er dus een \textit{StartFilter} aangemaakt. Deze \textit{parst} de filterstring die in dit geval dus een logische 'en' operator bevat. \textit{StartFilter} maakt bijgevolg een \textit{AndFilter} aan met als argument de opgesplitste filterstring. \textit{StartFilter} gaat deze twee filterstrings opnieuw parsen en detecteren dat deze strings geen operatoren meer bevatten. Voor elke string gaat hij dus een \textit{FilterObject} maken. Deze filterobjecten halen al de objecten op van de objectendatabase \textit{ObjectList} en voeren de filter erop uit. Op dit ogenblik is de volledige boom aangemaakt.\par
Nu gaat \textit{ObjectList} de methode \textit{join()} oproepen op de \textit{StartFilter}. Deze vraag propageert door de boom helemaal tot bij \textit{FilterObject} die zijn resultaat gaat teruggeven. Als dit resultaat van beide \textit{FilterObjects} aankomt bij de \textit{AndFilter} gaat hij de beide resultaten samenvoegen volgens de logische operator 'en'. Daarna gaat dit resultaat naar de \textit{StartFilter} die het terug doorgeeft aan \textit{ObjectList}. \textit{ObjectList} geeft het uiteindelijke resultaat dan terug aan de filter methode.
\begin{figure}[p]
\centering
\includegraphics[width=0.48\textwidth]{Sequence_Diagram1.jpg}
\caption{Het sequentiediagram van de filter methode}
\label{fig:sequentiefilter}
\end{figure}
\subsection{Ontwerpbeslissingen en patronen}
In deze sectie worden de ontwerpbeslissingen en gebruikte patronen in de implementatie van de uitbreiding van het project besproken.
\subsubsection{Object grafe}
De klasse \emph{GraphFrame} is een Singleton omdat er maar \'e\'en enkel frame nodig is waarop de grafe getekend wordt.
Via deze klasse kan de rest van het systeem communiceren met het grafisch gedeelte. Deze klasse is als een Singleton ge\"implementeerd, omdat er maar \'e\'en venster met de object grafe nodig is. Bovendien biedt dit het voordeel dat de referentie naar de \emph{GraphFrame} nergens hoeft doorgegeven te worden. Deze kan rechtstreeks opgevraagd worden via de statische methode \textit{GraphFrame.getInstance()}.
\par
Om de layout van de object grafe makkelijk aanpasbaar te houden, hebben we twee \emph{strategies} gebruikt, namelijk \textit{GraphPlacementStrategy} en \textit{LineStrategy}. Subklassen van deze interfaces implementeren algoritmen om eenerzijds de \emph{GraphObjects} te plaatsen en anderzijds de lijnen tussen deze \emph{GraphObjects} te trekken. Dankzij deze \emph{strategies} is het simpel om de onderliggende algoritmen te vervangen. Zo implementeert de \emph{GridLayoutStrategy} een plaatsingsalgoritme dat de \emph{GraphObjects} plaatst op een raster, terwijl de \emph{CircularLayoutStrategy} de \emph{GraphObjects} op een cirkel plaatst.
\par 
Om de object grafe te tekenen moeten de \emph{GraphPlacementStrategy} en de \emph{LineStrategy} echter samenwerken. Er kunnen immers geen lijnen getrokken worden alvorens de \emph{GraphObjects} op de juiste plaats staan. De \emph{GraphMediator} is een toepassing van het \emph{Mediator} patroon dat de samenwerking van de \emph{strategies} gaat co\"ordineren zodat ze zelf niets van elkaar hoeven af te weten. Het \emph{Mediator} patroon promoot immers \emph{Loose Coupeling}. De implementatie is als volgt: de \emph{GraphMediator} is de \emph{``Mediator''} interface en de \emph{GraphComponent} is de \emph{``ConcreteMediator''} die de \emph{GraphMediator} implementeert. De \emph{``Colleague''} zijn de klassen die de interface \emph{GraphStrategy} implementeren. Dit zijn de interfaces \emph{GraphPlacementStrategy} en \emph{LineStrategy}. De samenwerking is als volgt: de \emph{GraphComponent} gaat de \emph{GraphObjects} plaatsen en daarna proberen om er lijnen tussen te trekken. In sommige gevallen zal het zo zijn dat er niet genoeg plaats is voor de \emph{LineStrategy} om de lijnen te trekken zonder dat deze elkaar overlappen. Indien dit het geval is, kan de \emph{LineStrategy} via de \emph{GraphMediator} vragen om de \emph{GraphObjects} verder uit elkaar te plaatsen.
\par 
De klasse \emph{GraphObject} encapsuleert al de data die nodig is om het object te tekenen, te plaatsen en om de interacties tussen de \emph{GraphObjecten} weer te geven.
\subsubsection{Filter}
In het filter gedeelte is er steeds een klasse nodig die alle aangemaakte objecten bijhoudt die zowel rechtstreeks als onrechtstreeks worden aangemaakt in de \emph{objectbench} van BlueJ. Deze klasse kan het best als \emph{singleton} ge\"implementeerd worden, omdat hier maar \'e\'en van in omloop mag zijn. Deze klasse kan men beschouwen als de databank van de objecten en hier is er slechts \'e\'en exemplaar van nodig om het overzicht te kunnen bewaren. Indien er in de toekomst toch verschillende 'databanken' nodig zijn, is het eenvoudig om dit aan te passen. Deze klasse is uiteindelijk \textit{ObjectList} geworden in ons ontwerp. Dit patroon heeft ook het voordeel dat de 'database' steeds aangesproken kan worden om deze up te daten. Het is niet nodig om het effectieve object in parameters mee te geven en zo aan te spreken, aangezien een instantie van deze klasse statisch kan opgehaald worden. \par
Om te bepalen welke klasse de verantwoordelijkheid van het filteren krijgt, hebben we het \textit{GRASP} patroon \textit{Information Expert} gebruikt. De klasse die filtert moet de klasse zijn die over alle informatie bezit die hiervoor nodig is. Dit is \textit{ObjectList} geworden. Deze klasse bevat al de objecten die rechtstreeks of onrechtstreeks aangemaakt zijn in BlueJ. Het is dan ook logisch dat deze klasse de verantwoordelijkheid voor het filteren van deze objecten en zijn velden op zich neemt.
\par
\textit{ObjectList} maakt ook nieuwe \textit{ObjectRepresentations} aan. Aangezien hij al deze objecten bevat is hij volgens het \textit{GRASP} patroon \textit{Creator} een goede kandidaat om deze verantwoordelijkheid te vervullen.
\par
Voor het combineren van logische operatoren is het ontwerppatroon \textit{Composite} zeer geschikt. Aangezien we 'en', 'of' en 'niet' operatoren makkelijk kunnen combineren in een boomstructuur (zie figuur \ref{fig:filterboom}). Het enige verschil is dat er hier maar \'e\'en klasse als \textit{leaf} wordt gebruikt en dat de \textit{Composite} klasse maar twee zijden bevat. Op die manier is het makkelijk om de filterstring op te splitsen en later de verschillende gefilterde lijsten terug samen te voegen volgens de juiste methode.


\subsection{Problemen en beperkingen}
\section{Testen}
\subsection{Grafisch gedeelte}
Het grafische gedeelte is inherent moeilijk om te testen dan de \emph{``Business Logic''}, omdat er veel gebruiker interacties zijn.
De klassen die hier niet onder lijden: \emph{GraphObject}, \emph{RectangularLine}, \emph{GridLayoutStrategy} en \emph{CircularLayoutStrategy} worden wel grondig getest. Voor de klasse \emph{GraphObject} wordt nagegaan of de meegegeven parameters in de constuctor correct worden
opgeslagen in het object. Dit is belangrijk, want indien dit niet het geval zou zijn, toont de object grafe incorrecte waarden en connecties tussen velden. De klasse \emph{RectangleLine} dient ook grondig getest te zijn. Tijdens het plaatsen van lijnen is het belangrijk dat de lijnen elkaar niet overlappen, omdat het anders niet duidelijk is naar waar de verwijzing leidt. Hetzelfde geldt voor de klasse \emph{GridLayoutStrategy} en \emph{CircularLayoutStrategy}. Indien de \emph{GraphObjects} over elkaar geplaatst worden, is het onmogelijk voor de gebruiker om een overzicht te krijgen van de applicatie.
\subsection{Filter gedeelte}
Het filteren is ook moeilijk te controleren met Unit testen. De filter werkt immers met \textit{objectReferences} van het \textit{com.sun.jdi} pakket. Deze objecten zijn moeilijk te maken binnen unit testen. Het gedeelte van de code werd dus voornamelijk getest door BueJ op te starten en de reactie van het systeem op bepaalde input te analyseren. Dit is ook de reden waarom er bij BlueJ zelf zo weinig unit testen bijgevoegd zijn. Enkel de \textit{parser} is daar goed getest omdat deze geen gebruik maakt van het \textit{jdi} packet. Ook bij de uitbreiding werd de parser getest met unit testen.
\section{Kritische reflectie}

Om zelf een kritisch beeld te krijgen over de code zijn de tools die gebruikt werden in de vorige iteratie om BlueJ te analyseren nog eens toegepast op onze toegevoegde code. Dit laat ons toe om zelf de kwaliteit van de code in te schatten en eventuele aanpassingen te maken indien dit nodig zou blijken. De gebruikte tools zijn EclEmma, FindBugs, inCode en CodeCity.

\subsection{EclEmma}
EclEmma is een \emph{code coverage tool} die nagaat welke delen van de code \emph{gecoverd} worden door de JUnit tests. Onderstaande figuur toont de output van EclEmma, toegepast op de JUnit testen van onze uitbreiding.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{eclemmacodecoverage.png}
\caption{Output van EclEmma code coverage tool}
\label{fig:eclemma}
\end{figure}
Uit deze figuur blijkt dat onze code voldoende \emph{gecoverd} wordt door de JUnit testen. Maar zoals reeds besproken in de vorige sectie zijn sommige onderdelen van de code niet getest. Meestal omdat het gewoon onmogelijk is om de testen uit te voeren, omdat de nodige objecten niet bereikt of aangemaakt kunnen worden, of omdat er gebruikersinteracties nodig waren.

\subsection{FindBugs}
FindBugs is een \emph{tool} die automatisch fouten detecteert in de code. Hierbij is er wel enige voorzichtigheid geboden, want zo een \emph{tool} heeft enkel wat \emph{templates} van fouten, die het gaat zoeken in de code. Dit kan vaak ``false positives'' geven. Onderstaande afbeelding  toont de \emph{output} van FindBugs.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{findbugsresults.png}
\caption{Output van FindBugs}
\label{fig:findbugs}
\end{figure}
FindBugs vindt dertien fouten in het project, maar een aantal van deze fouten zijn ``false positives'' zoals de \emph{Inefficient use of keySet iterator instead of entrySet iterator}. Uit de code blijkt dat de \emph{keys} daadwerkelijk gebruikt worden en dat het onmogelijk is om te itereren over de \emph{entrySet}. De overige fouten zijn eerder stijlfouten die weinig of geen invloed hebben op de uitvoering van de code. Het zou bijvoorbeeld effici\"enter zijn om een \emph{StringBuilder} te gebruiken om \emph{Strings} te concateneren, maar gewoon de + operatie gebruiken werkt evengoed.

\subsection{inCode}
inCode analyseert de code en toont eventuele design problemen. Verder genereert inCode een overzichtspiramide met data zoals het aantal packages, het aantal klassen, aantal methodes enzovoort. De onderstaande figuur toont de output van inCode.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{incodeoverview.png}
\caption{Output van inCode}
\label{fig:incode}
\end{figure}
inCode geeft bovendien ook nog een aantal opmerkingen. Uit de figuur zien we dat de klassen veel methodes defini\"eren en dat er weinig klassen per pakket zijn. De klassen hebben veel methodes omdat ze al de methodes van de interfaces moeten implementeren. Deze omvatten veel getters en setters. Bovendien zijn er bewust veel pakketten aangemaakt. Dit is een anticipatie dat er in de toekomst meerdere subklassen ge\"implementeerd zullen worden van de interfaces \emph{GraphPlacementStrate}y en \emph{LineStraty}. Momenteel zitten deze subklassen in een aparte package, die dus maar \'e\'en enkele klasse bevat. Volgens inCode roepen onze methodes ook veel andere methodes aan, wat logisch is vermits onze code sterk moet interageren met de objecten van BlueJ. Daarom geeft inCode ook aan dat de klasse \emph{ObjectList Feature Envy} is want deze klasse interageert sterk met de \emph{ObjectWrapper} en \emph{ObjectRepresentation} klassen.

\subsection{CodeCity}
CodeCity genereert een visualisatie van de code in de vorm van een stad, waarin de gebouwen de klassen voorstellen. Hoe hoger de klasse, des te meer methodes er in die klasse zitten. Hoe breder de basis, des te meer velden er in de klasse zitten. Dit geeft snel een overzicht van de klassen met de grootste functionaliteit.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{codecityimage.png}
\caption{CodeCity visualisatie}
\label{fig:incode}
\end{figure}
De grootste klassen zijn \emph{GraphObject}, \emph{GridLayoutStrategy} en \emph{CircularLayout}. De klasse \emph{GraphObject} bevat een groot aantal velden met \emph{getters} en \emph{setters}, want deze moet correct een object voorstellen dat gevisualiseerd kan worden. De klassen \emph{GridLayoutStrategy} en \emph{CircularLayoutStrategy} hebben dan enkel veel methodes om de \emph{GraphObject} correct te plaatsen. 

\section{Management}
Zoals eerder gesteld werd het project opgedeeld in twee deelprojecten. Het verkrijgen van alle aangemaakte objecten en het kunnen filteren van deze objecten werd ge\"implementeerd door Leendert en Thibaut. Het grafische aspect werd onder handen genomen door Niels en Jorn.
\par
\begin{tabular}{|l|l|l|l|l|}
\hline
& Jorn & Leendert & Thibaut & Niels\\
\hline
Analyse \& aanpak & 4 & 4 & 4 & 4\\
\hline
Verkrijgen van objecten + filter & &&&\\
\hline
Grafisch & &&&\\
\hline
Testen & &&&\\
\hline
Verslag & &&&\\
\hline
Totaal & &&&\\
\hline
\end{tabular}
\section{Discussie en Conclusie}
\end{document}